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Abstract 


Flash technology is being utilized in fuzed munition applications and, 
based on the development of digital logic devices in the commercial world, usage of 
flash technology will increase. Digital devices of interest to designers include flash- 
based microcontrollers and field programmable gate arrays (FPGAs). 


Almost a decade ago, a study was undertaken to determine if flash-based 
microcontrollers could be safely used in fuzes and, if so, how should such devices be 
applied. The results were documented in the “Technical Manual for the Use of Logic 
Devices in Safety Features.” 


This paper will first review the Technical Manual and discuss the rationale 
behind the suggested architectures for microcontrollers and a brief review of the 
concern about data retention in flash cells. An architectural feature in the 
microcontroller under study will be discussed and its use will show how to screen for 
weak or failed cells during manufacture, storage, or immediately prior to use. As was 
done for microcontrollers a decade ago, architectures for a flash-based FPGA will be 
discussed, showing how it can be safely used in fuzes. Additionally, architectures for 
using non-volatile (including flash-based) storage will be discussed for SRAM-based 
FPGAs. 


Outline 


Fuze engineering working group discussions 
— Technologies for logic devices (antifuse, EEPROM, Flash, etc.) 


Example (non-DoD): EEPROMs and Single Board 
Computers 


Technical Manual criteria for use of Flash/EEPROM 
uController architectures 


FPGA Architecture and Capabilities for flash cell 
validation 


Performance characterization 


Logic Device Technology 


shall use the least complex logic device that can practically perform the required 
functionality. 


2.2. While fixed-in-structure devices are acceptable and preferred, to avoid 
degradation of a safety feature, any logic device used in the implementation of 
that feature: 


2.2.a. Shall not be re-programmable. 


2.2.b. Shall not be alterable by credible environments.. 


2.2.c. Shall not have the SF logic configuration reside on volatile 


memory. 


2.2.d. Should be rated to meet or exceed the lifecycle environments of 
the system. Shall have engineering rationale provided and 
associated risk(s) for logic devices not rated to meet or exceed the 
lifecycle of the system. 


Nw 
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In order to minimize the potential for common cause failures, where all SFs are 
implemented with logic devices, at least two SFs shall be implemented with 
dissimilar logic devices. The degree of dissimilarity shall be sufficient to ensure 
that any credible common cause susceptibility will not result in unsafe operation 


From DoD Fuze Engineering Standardization Working Group, “Technical Manual for the Use of Logic Devices in 
Safety Features,” March 8, 2011. 
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A Typical uP-Based Computer 


EEPROM 


Not a recommended architecture. 


GSFC NASA ADVISORY 


Goddard Space Flight Center 


1. Advisory Number 2. Subject 
NA-GSFC-2005-04 Application of Hitachi 1-Mbit Die Based EEPROM Technology to Space Applications. 


3. Manufacturer 4. Manufacturer CAGE Code 5. Federal Stock Code 
Several manufacturers package this part and sell N/A N/A 
it under their brand name and part number. 


6. Part/Material/Process Number 7. Lot Date Code/Serial Number | 8. Controlling Spec/Document Number 
Various All 5962-38267 
Various; Used on RAD 6000 & RAD 750. 


9. References 
See page 3. 


GENERAL INFORMATION: This is a NASA Advisory issued by the Goddard Space Flight Center (GSFC) in accordance with the 
requirements of NASA Procedures and Requirements 8735.1A. For information concerning processing and actions required to be 
conducted in conjunction with this information, refer to your contract, or to NASA Procedures and Requirements 8735.1A. This information 
has been compiled and presented as accurately, completely, and objectively as possible consistent with the primary objective of alerting 
potentially affected projects as early as possible. This information may be altered, revised, or rescinded by subsequent developments or 
additional tests; and these changes could be communicated by other NASA documents. Neither NASA, the United States Government, nor 
any person acting on its behalf assumes any liability resulting from any distribution or use of this information. 


10. DISTRIBUTION: While the primary distribution for this document is internal to NASA personnel and NASA contractor personnel, the 
information contained in this document is factual, and its release to, and use by, other entities is not restricted. 


11. Problem Description and Details: 


Reports of failures associated with the use of Electrically Erasable Programmable Read Only Memory (EEPROM) technology-based devices 
used by the aerospace industry have recently become widespread. Documented failures center around systems based on the Hitachi 
HCN58C1001 1-Mbit commercial die. The Hitachi die is packaged by various vendors into either single chip packages or multi-chip 
modules. This advisory is applicable for the use of Hitachi 1-Mbit die based components in both custom in-house designs as well as 
integrated into commercially available products as is the case with flight computer boards available from several vendors. Note: Hitachi no 
longer makes this die and the organization which previously made the die is now part of a different company. 


Available evidence does not show conclusively whether this situation is a result of an inherent defect in the semiconductor die or may result 
from an anomaly during programming. 
(See continuation on page 2) 
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12. Actions Recommended: (Continued from page 2) 


The implementation of redundancy can reduce the risk of mission failure due to a single point failure. For this approach to be effective, the 
determination of which side to power up can not be made by software executing from volatile memory. A hardware decoded command is the 
recommended approach. 


The design can incorporate the capability to provide Direct Memory Access (DMA) to volatile memory independent of local controller or 
processor involvement. This allows for the EEPROM, or other type of memory, to be loaded directly and verified by an external source such 
as the S/C, off-board PROM, or command interface. In this way, failed portions of the memory space can be avoided by relocating the 
executable code as needed. 


A less desirable architecture consists of multiple copies of the flight code to be stored in multiple EEPROM modules. A hardware decoded 
command determines from which EEPROM module the boot code will execute. 


An even less desirable implementation consists of multiple copies of the flight code to be stored in multiple EEPROM modules, but with the 
decision from which EEPROM module the boot code will execute being made by a small block of decider code in the startup EEPROM. In 


this case the decider code is required tobe already executing properly in order to verity and select ne boot code LEPROM. Ins 


implementation is dependent on the decider code portion of the flight software not being corrupted. A failure in that region of the startup 
EEPROM will result in a fatal failure. 


The least desirable and highest risk approach consists of a single EEPROM containing the boot code and a single copy of the executable 
code. A slight improvement would be to include multiple copies of the executable code to mitigate the risk of failure in certain parts of the 
EEPROM. 

The use of Error Detection and Correction (EDAC) is recommended, but can not be relied upon totally to compensate for single “weak bits”. 
The reason being that in the cases of a slow acting or an oscillating bit failure, the output of the EDAC circuitry could be indeterminant due to 
the voltage transitions applied to its inputs while it performs its computations and the propagation delays inherent within the EDAC circuitry. 


The memory access time of the EEPROM should be extended as much as feasible to provide added time for slow acting “weak bits” to reach 
the proper voltage level. 


In addition to system architecture, there are mitigation strategies that can be applied at the component level. These are discussed next. 


At the most basic level, designers must insure that all manufacturer component specifications and recommendations are properly 
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A Typical uP-Based Computer 


EEPROM 


Not a recommended architecture. 


Memory Validation Required 


Since, any changes to the SF hardware can adversely compromise the safety of 
the design, it is critical to establish and maintain a stable configuration 
throughout the lifecycle of the SF. A programmable logic device, including 
associated memory devices, may be considered as satisfying the requirements of 
paragraph 2.2 if, once programmed or configured during manufacturing, the 
configuration of its internal logic cannot be changed. Additionally, for devices 
relying on charged-based memory to implement a SF, a method of validating 
the integrity of the memory shall be performed prior to executing the safety 
function. The memory must be validated with the rigor equivalent to, or better 
than, that o: ofa 16 wah C eae Resineant Check sGs os This com poe result 


The aa Tey hall (1) Be fixed-i in-structure, Q2) te sedated aren 
(3) not contain and be exclusive from any other functions, and, (4) when 
feasible, not be implemented as part of any other SF. Consult with the 
appropriate Service Safety Authority for guidance. A notional example of an 
internal and external memory validation is provided below: 


From DoD Fuze Engineering Standardization Working Group, “Technical Manual for the Use of Logic Devices in 
Safety Features,” March 8, 2011. 
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Memory Validation:uC Example 


Pass/Fail 


Reset 


ee ed ee 


Internal Memory Validation External Memory Validation 


From DoD Fuze Engineering Standardization Working Group, “Technical Manual for the Use of Logic Devices in 
Safety Features,” March 8, 2011. 
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Multi-standard User I/O (MSIO) 


SmartFusion2 FPGA Architecture 


JTAG 1/0 SPI I/O Multi-standard User I/O (MSIO) 
Microsemi® SmartFusion’2 SoC FPGA 
Microcontroller Subsystem (MSS) 
SPI x 2 
Ghaue MMUART x 2 
System Controller I2C x2 MPU 
Timer x 2 
AES256 SHA256 SRAM-PUF 
CAN 
ECC NRBG APB PDMA HS USB SYSREG 
In-Application OTG ULPI 
Programming WwDT 
Flash*Freeze 
RTC 
AHB Bus Matrix (ABM) 
FIC | | | 
COMM_BLK FIC_O FIC_1 
Interrupts APB AHB AHB 


Micro SRAM 
(64x18) 


Micro SRAM 
(64x18) 


[cons | | AXI/AHB/XGXS 


Serial Controller 0 
(PCle, XAUI/XGXS) 
+ Native SERDES 


Serial 0 1/0 


From Microsemi documentation. 


ARM® Cortex™-M3 


| 


TSE MAC 


Instruction 


Cache 
ETM 
DDR 
OM Bridge 


| | 
rae 


eSRAM HPDMA 


DDR User I/O 


MSS 
DDR Controller 
+ PHY 


SMC_FIC] Config AXI/AHB 


FPGA Fabric (Up to 150K Logic Elements) 


Large SRAM 
(1024x18) 


Large SRAM 
(1024x18) 


[con | | AX\/AHB/XGXS 


Serial Controller 1 
(PCle, XAUI/XGXS) 
OSCs + Native SERDES 


Serial 1 /O 


PLLs 
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Math Block 
MACC (18x18) 


- 
- 
- 
- 


Math Block 
MACC (18x18) 


Joon [unre 


Fabric DDR 
Controller + PHY 


DDR User I/O 


Standard Cell/ 
SEU Immune 


Flash Based/ 
SEU Immune 
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Smartfusion2 Fabric Configuration and eNVM 
(non-volatile memory) Integrity Tests 


SmartFusion2 and |GLOO2 FPGA devices have a novel NVM integrity check mechanism that can 
optionally be used to check the reliability and security of a device automatically upon power-up, or upon 
‘demand. The contents of all the nonvolatile configuration memory segments, including security keys, 
security settings, and the FPGA fabric configuration, plus any eNVM pages declared as ROM by the user 
(all the write-protected pages) are digested (hashed) using the SHA-256 algorithm. The results are 
compared to values stored in dedicated nonvolatile memory words located in each segment. If the 
contents are unchanged from when the digests were computed and stored during the original 
programming steps—that is, if the current and stored digests match—the test will pass; otherwise a 
failure is flagged. This test provides assurance against both natural and maliciously induced failures. 


Note: The FPGA fabric is non-operational while the test is running on the fabric. 

Ensure not to run the digest too often, as eventually the 20 year reliability of the flash cells will be 
affected. . Note that the digest verification of the fabric and each eNVM array can each be blocked with 
lock-bits. However, these can be overridden with a match of the FlashLock Passcode. 

The digests can be verified on-demand by the user, either internally using a system service, or externally 
using a programming instruction. In addition, the user can run digests check automatically upon each 
power-up. The following section describes the various options to run digest check. 


From Microsemi documentation. 
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Smartfusion2 Integrity Check 
(Power-up Digest Check) 


The Digest checks for the FPGA fabric and one or both eNVM arrays (if present) can be configured using 
lock-bits to run automatically upon each power-up. The Tamper macro in Libero SOC allows the user to 
set this option (refer to Figure 5-5) and the POWERUP_DIGEST_ERROR signal will allow the user to 
check the status of digest check.. Ce 


If the FPGA is selected for power-on digest check, there will be a noticeable delay due to the time 
required to run the hash algorithm on millions of bits (for example, one or two seconds) before it boots 


into normal operation. Also, the user must be careful and not run the digest often. 


From Microsemi documentation. 
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Smartfusion2 Integrity Check 
(Power-up Digest Check) 


Ss Configuring aaa_0 (TAMPER2 - 2.1.200) 


= Lv 


Configuration 
Enable LOCKDOWN_ALL Function [| 
Enable DISABLE_ALL_IOS Function [| 
Enable RESET Function re 
Zeroization 
i Enable ZEROIZE Function [i | 
Configuration 
Clk Frequency Error Detection 
Enable CLK Frequency Error Detection [| 
Tolerance 


Digest check on power up 


FABRIC digest check on power Up [| 


ENVM_0O digest check on power Up [| 


ENVM_1 digest check on power Up | 


(ox) [cance | 
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System Controller Checks Data Integrity 


NVM Data Integrity Check Service 


The NVM data integrity check service recalculates and compares cryptographic digests of the selected 
NVM component(s)—fabric, ENVMO, and ENVM1— to those previously computed and saved in NVM. 


The contents of all the nonvolatile configuration memory segments are digested (hashed) using the 
SHA-256 algorithm. The results are compared to values stored in dedicated nonvolatile memory words 
located in each segment. If the contents are unchanged from when the digests were computed and 
stored during the original programming steps—that is, if the current and stored digests match—the test 
will pass; otherwise a failure is flagged. 


The OPTIONS field in the NVM data integrity check service request selects the NVM components (fabric 
configuration, eNVMO, and eNVM'1) for data integrity check, Table 2-93. 


Table 2-93 « NVM Data Integrity Check Service Request 


fet [Length yes)| Feld | ‘eso 


Mf | OPTIONS Service options. Refer to Table 2-94. 


Table 2-94 * OPTIONS 


oe es 
a eee 


Reserved ENVM1 ENVMO FABRIC 
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Summary of Test Results 


Testing smartfusion2 devices for start up time with flash cell checking on startup. 
— Using on-chip 50 MHz RC oscillator driven off-chip as the device start indicator. 


Devices: 
¢ M2S005S: 6,060 Logic Elements, 128 kbytes ROM 
¢ M2S010TS: 12,084 Logic Elements, 256 kbytes ROM 
¢ M2S025TS: 27,696 Logic Elements, 256 kbytes ROM 
¢ M2SO90TS: 86,315 Logic Elements, 512 kbytes ROM 


— Nochecks enabled: start time < 1 ms 
¢ Used 50 us start time in device settings (this is a programmable value) 


— Fabric: flash cell checking enabled 


— NVM (non-volatile memories in on-chip computer): 
¢ Measured start times for 16k, 32k, 64k, 128k, 256k, and 512k memory sizes (size is programmable) 


— Preliminary Results for Fabric Checking (NVM Checking Disabled): Logic size vs. start time 
¢ M2S005S: 544 ms 
¢ M2S010TS: 897 ms 
¢ M2S025TS: 1,291 ms 
¢ M2SO090TS: 2,530 ms 


Typical Measurement Scheme 
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M2SO90TS Measurement Scheme 
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System Controller Clocked by RC Oscillator 


Clock Requirements 


The System Controller is clocked by the on-chip 50 MHz RC oscillator. 

It is powered by the VDD power pins and does not require external components for operation. The Chip 
Oscillators macro need not to be instantiated in the design for System Controller operation since it has a 
dedicated hardwired connection from the 50 MHz RC oscillator. 


en DASHES a ae emer aeon 60th Annual Fuze Conference, May 9-11, 
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RC Oscillator Specification 


y ¢ Electrical Characteristics of the 50 MHz RC Oscillator 


Table 


Parame Description Condition Min Typ Max Units 
F50RC Operating frequency - - 50 - MHz 
050 Devices - 1 - % 
ACC50RC Accuracy - ° 7 
090 Devices 
010 and 150 Devices 
CYC50RC Output duty cycle - 46.5-53.5 
Period Jitter 
005, 010, 050, and 060 Devices 300 
150 Devices 400 
025 and 090 Devices 500 
JITSORC Output jitter (peak to peak) 
Cycle-to-Cycle Jitter 
005 and 050Devices 
010, 060, and 150 Devices 
025 and 090 Devices 
IDYN50RC Operating current - 


een DSH eS ia ae inentanon: 60th Annual Fuze Conference, May 9-11, 
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Upcoming Work 


Table 24+ Integrity Check Function 


Function JTAG/SPI command 
Export digest and C-of-C (during bitstream Yes! 

programming) 

Export digest stored during programming (on Yes? 

demand) 

Compute/Export Fresh Digest (on demand) Yes? Se 
Compute/Report Fresh Flag (on demand) Yes‘ Yes* 

Compute/Report Fresh Flag (after Power-on-Reset) |— Yes” 


ae 


As part of bitstream programming (FRAME_DATA JTAG/SPI commands): The digests and C-of-Cs 
(MACs) of the newly programmed data are exported for each included bitstream segment (BITS, 
KEYS, FPGA, eNVM, EOB) as they are loaded. Not available as a system service with IAP. 
READ_DIGESTS JTAG/SPI commands: On demand, exports digests that were previously 
computed and stored during programming for the Fabric, and for the eNVMO and eNVM1 ROM'd 
pages. 

CHECK_DIGESTS JTAG/SPI commands: Fresh flags for all the security segments, the FPGA 
fabric, the eNVMO & eNVM1 ROM'd pages, and the private eNVM. Immediately after running the 
CHECK_DIGESTS command, the fresh digests for the FPGA fabric, eNVMO and eNVM1 can be 
exported. 

DIGEST CHECK system service: Computes fresh flags on demand for the FPGA Fabric, the eNVMO 
and eNVM1 ROMVMO & eNVM1 ROM’d pages, and the system controller ROM. 
POWER-ON-RESET DIGEST system service: Immediately after power-up, fresh flags for the same 
data as DIGEST CHECK can be read (only available if PoR digest option is selected in security 
policy). 


From Microsemi documentation. UGO443, Rev. 8, July 2016. 
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Conclusion 


Appears Technical Manual criteria for validating configuration memory in 
flash-based FPGAs can now mostly be met. 
— FPGA includes a uP, flash and RAM memories, and peripherals 
— Comparison done in a separate internal section but not an external device. 
— Next year’s work to investigate exporting checksum for external comparison. 


Stronger validation check then notional uwController architecture 


— wucController architecture relies on small amount of flash being functional for 
small memory scanning/CRC calculating software routine. 


— Time for validation is not specified by manufacturer. 


Validation time dependent on: 
— Size of FPGA “fabric” (logic area) 
— Amount of non-volatile memory used in the application. 
— Frequency of on-chip ring oscillator. 
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